1. Field of the Invention
The present invention relates to information technology. More specifically, the present invention relates to the configuration of data processing systems.
2. Related Art
Data processing systems with distributed architecture are commonly used to run a number of software applications. In a distributed architecture, client computers exploit services offered by server computers across a network. A typical example is that of a server farm, which consists of a collection of servers, typically housed in the same location, offering the required services.
For this purpose, the servers are combined so as to appear as one or more application areas to the clients. In this way, the server farm can exploit the power of the multiple servers for processing the enormous amount of service requests that are routinely submitted in several environments (such as in large companies or on the Internet). Moreover, the server farm provides a single point of management and facilitates the scaling of the system. At the same time, the server farm ensures a high reliability since its operation may be recovered even in case of failure of one or more servers. Typically, the server farm also implements load-balancing techniques, which are used to distribute the workload among its individual servers; moreover, this allows scheduling the processing of the incoming service requests (for example, according to different priorities).
The configuration of a server farm is a complex process. Indeed, the required servers may be acquired from a number of vendors; moreover, each vendor can offer a wide range of models, each one available in multiple versions (such as with different processors, working memory, and the like). Therefore, a huge number of configurations of the server farm (each one defined by a combination of selected servers) are available. Moreover, many of the available configurations are eligible to implement the server farm, since they exhibit characteristics meeting operational constraints imposed by the software application to be run (such as the necessary processing power, working memory, and the like). Therefore, it is very difficult to select one out of the eligible configurations that optimizes specific design parameters (such as a total cost of the server farm). For example, in some situations it would be preferable to consolidate the server farm on a few servers with many processors, whereas in other situations it would be preferable to distribute the same server farm throughout many servers with a few processors. Likewise, it would be possible to provide the servers with large or small memories, at the same time reducing or increasing their number, respectively.
The problem is exacerbated when the software application features a multi-tier architecture, with different modules having distinct requirements (in terms of processing power and working memory in the example at issue). A typical example is that of the System Applications and Products in data processing (SAP™) by SAP AG; the SAP application consists of an integrated suite of products that allow interacting with a common database for a comprehensive range of services (such as for managing financial, asset, cost accounting, production, human resources, logistic, document archive, customer relationship and supply chain operations). In this case, the server farm is not homogeneous and includes different servers for the corresponding modules. Particularly, in the example of the SAP application, DBMS servers are required to host DBMS instances (managing the common database), and application servers are required to host application instances (managing the offered services).
Therefore, the process of configuring the server farm becomes quickly unmanageable manually for a system designer. The current practice is then of using rule-of-thumbs and intuition to select the desired configuration. However, this requires a trial and error approach to ensure that the selected configuration actually meets the operational requirements of the software application and provides an acceptable result in terms of the design parameters. Therefore, the resulting server farm (corresponding to the selected configuration) is commonly oversized; indeed, the safest configuration is always selected (as a precautionary measure) in the impossibility of identifying the configuration that is actually optimal. In any case, the result strongly depends on the skill of the system designer.
Moreover, the difficulty of the configuration process does not allow taking into account more complex scenarios. For example, the problem of providing acceptable performance of the server farm (even in case of failure of one or more servers) is generally disregarded. Further, the configuration of the server farm is selected without coping with the problems involved by the possibility of consolidating multiple (virtual) servers on one or more physical computers.
In any case, the obtained results are always based on the current situation when the configuration of the server farm is selected. Therefore, the selected configuration (even if acceptable at the moment) may involve problems when it must be upgraded in the future. For example, a configuration of the server farm adapted to the current workload may become quickly inadequate because of an increase of the service requests; in this case, it is possible that the cost of changing one or more servers may defeat the initial saving.